How it works on main

The COS reconciler checks if a revision took too long to roll out. If it did, it sets
Progressing=False/ProgressDeadlineExceeded.

To avoid a reconcile loop after that, main has a watch predicate that blocks all
updates to COS objects with ProgressDeadlineExceeded. The predicate only allows
deletions through.

What is the problem?

The predicate blocks too much. It blocks all updates, not just status updates.

Example: a new revision rolls out and tries to archive the old stuck one by patching
lifecycleState: Archived. The predicate sees ProgressDeadlineExceeded and drops the
event. The old revision never gets archived.

Example scenario

1. User installs a ClusterExtension. The CE controller creates COS-rev-1.
2. COS-rev-1 gets stuck (e.g. a Deployment never becomes ready). After
   ProgressDeadlineMinutes, the reconciler sets Progressing=False/ProgressDeadlineExceeded.
3. User updates the ClusterExtension. The CE controller creates COS-rev-2.
4. COS-rev-2 rolls out successfully. It patches COS-rev-1 with lifecycleState: Archived
   so the old revision gets cleaned up.
5. The watch predicate sees COS-rev-1 has ProgressDeadlineExceeded and drops the event.
   COS-rev-1 never reconciles, never processes the archival, and stays stuck forever.

Why does the reconcile loop happen?

Every time the reconciler runs on a deadline-exceeded COS, it calls markAsProgressing()
which sets Progressing=True. Then the deadline check immediately sets it back to
Progressing=False/ProgressDeadlineExceeded. This back-and-forth produces a status
update, which triggers another reconcile, and so on.

The predicate was added to break this loop. But it also breaks archiving.

What is the fix?

1. Make ProgressDeadlineExceeded sticky (prevents reconcile loop)

Once ProgressDeadlineExceeded is set, markAsProgressing() will not overwrite
it with RollingOut for Active revisions. This prevents the status flip-flop
that caused the reconcile loop.

The guard only blocks RollingOut. Other reasons (Succeeded, Retrying) can
still update the condition because they represent meaningful state changes.

With no flip-flop, there are no unnecessary status updates, so no reconcile
loop. The watch predicate is removed.

2. Skip progress deadline enforcement for Archived revisions

The deadline check now skips Archived revisions:

if pd > 0 && lifecycleState != Archived {
    // deadline check logic
}

This allows Archived revisions to retry teardown operations and update their
status without being overridden by the deadline check.

3. Detect spec changes during rollout (resolution digest)

A SHA256 digest of all catalog filter inputs (packageName, version, channels,
selector, upgradeConstraintPolicy) is stored in the revision's
olm.operatorframework.io/resolution-digest annotation.

Before reusing a rolling-out revision, the controller compares the current
spec's digest with the revision's digest. If they differ, a new revision is
created.

This ensures spec changes are not ignored when a revision has
ProgressDeadlineExceeded.

How it works

1. Archival: A new successful revision can archive old revisions with
   ProgressDeadlineExceeded
2. Deletion: Users can delete ClusterExtensions with stuck revisions
3. Spec changes: Users can update catalog filters even while a revision is rolling out
4. Error visibility: Retrying conditions are visible even after deadline exceeded
5. No reconcile loops: Status updates stabilize once deadline is exceeded

Motivation

Addresses feedback from:
openshift/operator-framework-operator-controller#687 (comment)